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1.0 Scope 


This document is a specification of the on-media 
structure that is used by Files-11. Files-11 is a general 
purpose file structure which is intended to be the’ standard 
file structure for all medium to large PDP=-11 systems. 
Small systems such aS RT=-11 have been specifically excluded 
because the complexity of Files-11 would impose too grech a 
burden on their simplicity and small size. 


This document describes structure level 1 of Files-1ll, 
also referred to as ODS=1 (on-disk structure version $1). 
This has been implemented on the RSX-11 family, (RSX-11M, 
RSX-11M-PLUS, IAS, and RSX=+11D) and on VMS. This document 
describes the final level of functionality for ODS-1. 
Structure level 2 (ODS-2) has been implemented on VMS and is 
the basis for all new disk structure enhancements. 


1.1 Summary of revisions made to this specification 
1. Expanded File Characteristics tto include most ODS~2 
options. ; 


2e Corrected H.FPRO to H.DFPR. 


3. Added new fields to home block for date and count of 
* home block modifications. 


4. Added Single Directory Support description and home 
block field. 


5. Added field in home block for pack serial number 
(H.PKSR). 


6. Added description of modified storage control  biock 
format to support large disks. 


7. Restricted maximum number of blocks supported on a 
volume to 1,644,488. 


8. Restricted ODS-1 to one block "clusters". 
9. Restricted ODS-1 to single volume structures. 


18. Clarified and expanded references to operating system 
support and relationship to ODS~-2. 


11. Removed RMS=11 definitions, to be provided in separate 
specification common to ODS-1 and ODS=2. 
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2.Aa Medium 


Files-1l is a structure which is imposed on a_= medium. 
That medium must have certain properties, which are 
described in the following section. Generally speaking, 
block addressable storage devices such as disks and Dectape 
are suitable for Files-1ll; hence Files-11 structured media 
are generically referred to as disks. 


Doyvd Volume 


The basic medium that carries a Files-1ll structure is 
referred to as avolume. A volume (also often referred to 
as a unit) is defined as an ordered set of logical blocks. 
A logical block is an array of 512 &bit bytes. The logical 
blocks in a volume are consecutively numbered from @ to n-l, 
where the volume contains n logical blocks. The number 
assigned to a logical block is called its logical block 
number, or  LBN. Files-11 is theoretically capable of 
describing volumes up to 232 blocks in size. In practice, a 
volume should he at least 198 blocks in size to be useful; 
current implementations of Files-11l will handle volumes up 
to 224 hlocks. 


The logical blocks of a volume must be- randomly 
addressable. The volume must also allow transfers of any 
length up to 65k bytes, in multiples of four bytes. When a 
transfer is longer than 512 bytes, consecutively numbered 
logical blocks are transfered until the byte count is 
Satisfied. In other words, the volume can be viewed as a 
partitioned array of bytes. It must allow reads and writes 
of arrays of any length less than 45k bytes, provided that 
they start on a logical block boundary and that the length 
is a multiple of four bytes. When only part of a block is 
written, the contents of the remainder of that logical block 
will be undefined. 


Peo Volume Sets 


This section is of historical interest only. ODS=1 
does not and will not support volume sets. A volume set is 
a collection of related units that are normally treated as 
one logical device in the usual operating system concept. 
Fach unit contains its own Files-1ll structure; however, 
files on the various units in a volume set may be referenced 
with a relative volume number, which uniquely determines 
which unit in the set the file is located on. Other 


sections in this specification will make occaSional 
reference to volume sets and relative volume numbers where 
hooks for their implementation exist. Since volume sets 


have not been implemented as yet, however, no complete 
specification is provided here. 
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3.0 Files 


Any data in a volume or volume set that is of any 
interest (i.e., all blocks not available for allocation) is 
contained in a file. A file is an ordered set of virtual 
blocks, where a virtual block is an array of 512 8 bit 
bytes. The virtual blocks of a file are consecutively 
numbered from 1 to n, where n blocks have been allocated to 
the file. The number assigned to a virtual block is called 
(obviously) its virtual block number, or VBN. Each virtual 
block is mapped to a unique logical block in the volume set 
by Files-il. Virtual blocks may he processed in the same 
manner aS logical blocks. Any array of bytes less than 45k 
in length may be read or written, provided that the transfer 
Starts on a virtual block boundary and that its length is a 
multiple of four. 


Ser d File ID 


Each file in a volume set is uniquely identified hy a 
File ID. A File ID is a binary value consisting of 48 bits 
(3 PDP-11 words). It is supplied by the file system when 
the file is created, and must be supplied by the user 
whenever he wishes to reference a particular file. 


The three words of the File ID are used as follows: 


Word 1 File Number 

Locates the file within a particular unit of the 
volume set. File numbers must lie in the range 1 
through 65535. The set of file numbers on a unit 
is moderately (but not totally) dense; at any 
instant in time a file number uniquely identifies 
one file within that unit. 


Word 2 File Sequence Number 


Identifies the current use of an individual file 
number on a unit. File numbers are re-used; when 
a file is deleted its file number becomes 
available for future use for some other file. 
Each time a file number is re-used, a different 
file sequence number’ is assigned to distinguish 
the uses of that file number. The file sequence 
number is essential since it is perfectly legal 
for users to remember and attempt to use a File ID 
long after that file has been deleted. 


Word 3 Relative Volume Number 


Identifies which unit of a volume set the file is 


located on. Volume sets are at present not 
implemented; the only legal value for the 
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Sane 


relative volume number in any context is zero. 


File Header 


Fach file on a Files-11 volume is described by a file 
header. 


The file header is a block that contains all the 


information necessary to access the file. It is not part of 


the 
file. 


header 


rather, it is contained in the volume's index 


(The index file is described in section 5.1). The 
block is organized into four areas, of which the 


first three are variable in size. 


Fa Awl 


Header Area 


The information in the header area permits’ the 
file system to verify that this block is in fact a 
file header and, in particular, is the header 
being sought by the user. It contains the file 
number and file sequence number of the file, as 
well as its ownership and protection codes. fMThis 
area also contains offsets to the other areas of 
the file header, thus defining their size. 
Finally, the header area contains a user attribute 
area, which may be used by the uSer to Store a 
limited amount of data describing the file. 


Ident Area 


The ident area of a file header contains 
identification and accounting data about the file. 
Stored here are the primary name of the file, its 
creation date and time, revision count, date, and 
time, and expiration date. 


Map Area 


The map area describes the mapping of virtual 
blocks of the file to the logical blocks of the 
volume. The mapping data consists of a list of 
retrieval pointers. Each retrieval pointer 
describes one logically contiguous segment of the 
file. © The map area also contains the linkage to 
the next extension header of the file, if such 
exists. 


End Checksum 


The last two bytes of the file header contain a 16 
bit additive checksum of the remaining 255 words 
of the file header. The checksum is used to help 
verify that the hlock is in fact a file header. 
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343 Extension Headers 
Since the file header is of fixed size, it is 


inevitable that for some files the mapping information will 
not fit in the allocated space. A file with a large amount 
of mapping data is therefore represented with a chain of 
file headers. Each header maps a consecutive set of virtual 
blocks; the extension linkage in the map area links the 
headers together in order of ascending virtual block 
numbers. 


Multiple headers are also needed for files that span 
units in a volume set. A header may only map logical blocks 
located on its unit; therefore a multi-volume file is 
represented by headers on all units that contain portions of 
that file. 


3.4 File Header ~ Detailed Description 


This section describes in detail the items contained in 
the file header. Each item is identified by a symbol which 
represents the offset address of that item within its area 
in the file header. Any item may be located in the file 
header by locating the area to which it belongs and then 
adding the value of its offset address. Users who concern 
themselves with the contents of file headers are _ strongly 
urged to use the offset symbols. The symbols may he defined 
in assembly language programs by calling and invoking” the 
macro FHDOFS, which may be found in the macro library of any 
system that supports Files-1l. Alternatively, one may find 
the macro in the file F11IMAC.MAC, which may be obtained from 
the author. 


lem as | Header Area Description 


The header area of the file header always starts at 
byte @. It contains the basic information needed for 
checking the validity of accesses to the file. 


3.4.1.1 H. INOF 1 Byte Ident Area Offset 
This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the ident area. It defines the location of the 
ident area and ‘tthe size of the header area. 


SeGeded H.MPOF 1 Byte Map Area Offset 


This byte contains the number of 16 bit words 
between the start of the file header and the start 
of the map area. It defines the location of the 
map area and, together with H.IDOF, the size of 
the ident area. 
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3.4.1.3 


3.4.1.4 


3.4.1.5 


3.4.1.4 


3.4.1.7 


H.FNUM 2 Bytes File Number 
This word contains the file number of the file. 
H.FSFO 2 Bytes File Sequence Number 


This word contains the file sequence number of the 
file. 


H.FLEV 2 Bytes File Structure Level 


The file structure level is used to identify 
different versions of Files-1l as they affect the 
Structure of the file header. This permits 
upwards compatibility of file structures as 
Files~ll evolves, in that the structure level word 
identifies the version of Files~11l that created 
this particular file. This document describes 
version 1 of Files-11; the only legal contents 
for H.FLEV is 4@1 octal. 


H. FOWN 2 Bytes File Owner UIC 
H. PROG H.FOWN+@ Programmer (Member) Number 
H. PROJ H.FOWN+1 Project (Group) Number 


H 


This word contains the binary user identification 
code (UIC) of the owner of the file. The file 
owner is uSually (but not necessarily) the creator 
of the file. 


H.F PRO 2 Bytes File Protection Code 


This word controls: what access all users in the 
system may have to the file. Accessors of a file 
are categorized according to the relationship 
between the UIC of the accessor and the UIC of the 
owner of the file. Each category is controlled by 
a four bit field in the protection word. The 
category of the accessor is selected as follows: 


System Bits @ - 3 


The accessor is subject to system 
protection if the project number of the 
UIC under which he is running is 194 
octal or less. 


Owner Bits 4 =~ 7 
The accessor is subject to owner 
protection if the UIC under which he is 


running exactly matches the file owner 
UIC. 
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364.148 


Group Bits 8 - il 


The accessor is subject to group 
protection if the project number of his 
UIC matches the project number of the 
file owner UIC. 


World Bits 12 - 15 


The accessor is subject to world 
protection if he does not fit into any 
of the above categories. 


Four types of access intents are defined in 
Files-1li: read, write, extend, and delete. Each 
four bit field in the protection word is bit 
encoded to permit or deny any combination of the 
four types of access to that category of 
accessors. Setting a bit denies that type of 
access to that category. The bits are defined as 
follows (these values apply to a right-justified 
protection field): 


FP.RDV Deny read access 
FP.WRV Deny write access 
FP.EXT Deny extend access 
FP.DEL Deny delete access 


When a user attempts to access a file, protection 
checks are performed in all the categories to 
which he is eligible, in the order system - owner 
~ group ~ world. The user is granted access to 
the file if any of the categories to which he is 
eligible grants him access. 


H.FCHA 2 Bytes File Characteristics 
H. UCHA H.FCHA+@ User Controlled Char. 
H.SCHA H.FCHA+1 System Controlled Char. 


The user controlled characteristics byte contains 
the following flag bits: 


~ 1 Bit, Reserved. 
UC.NID Set if incremental dump (backup) is to 
be disabled for this file. 
UC.WBC Set if the file is to be write-back 
cached; i.e., if a cache is used for 


the file data, data written by a user is 
only written back to the disk when is it 
removed from the cache. Clear for 
write-through cache operation. 
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UC.RCK Set if the file is to be read-checked. 3.4.1.9 H.UFAT 32 Bytes User Attribute Area 
All read operations on the file, 
including reads of the file header(s), This area is intended for the storage of a limited 
will be performed with a read, quantity of “user file attributes", i.e., any data 
read-compare to assure data integrity. the user deems useful for processing the file that 
is not part of the file itself. An example of the 
UC.WCK Set if the file is to be write-checked. use of the user attribute area is presented in 
All write operations on the file, section 6.1 (FCS File Format). 
including modifications of the file 
header(s), will be performed with a 3.4.1.1A S.HDHD 46 Bytes Size of Header Area 
write, read-compare_ to assure data 
: integrity. This symbol represents the total size of the 
header area containing all of the above entries. 
UC.CNB Set if the file is allocated contiguous 
best effort; i.,e., aS contiguous as 
possible. 3222 Ident Area Description 
UC. DLK Set if the file is deaccess-locked. The ident area of the file header begins at the word 
This bit is used as a flag warning that indicated by H.IDOF. It contains identification and 
the file was not properly closed and may accounting data about the file. 
contain inconsistent data. Access to 
the file is denied if this bit is set. ae eer & I.FNAM § Bytes File Name 
UC.CON Set if the file is logically contiguous; These three words contain the name of the file, 
i.e., if for all virtual blocks in the packed three Radix-5@ characters to the word. 
file, virtual block i maps to. logical This name usually, but not necessarily, | 
block k+i on one unit for some constant corresponds to the name of the file's primary 
k. This bit may be implicitly set or directory entry. 
cleared by file system operations that 
allocate space to the _ file; the user Sete a2 L.FTYP 2 Bytes File Type 


| 
| may only clear it explicitly. 
| This word contains the type of the file in the 
The system controlled characteristics byte form of three Radix-5@ characters. 
contains the following flag hits: 

364.263 I. FVER 2 Bytes Version Number 


= 3 Bits, Reserved. 
This word contains the version number of the file 


- Reserved (Access Control List). in binary form. 


S¢C.SPL Set if the file is an intermediate file 3.4.2.4 I.RVNO 2 Bytes Revision Number 


for spooling. 
This word contains the revision count of the file. 


SC.DIR Set if the file is a directory. The revision count is the number of times the file 
has been accessed for write. 


SC.BAD Set if there is a bad data block in the 
file. This bit is as yet unimplemented. oe ele I.RVDT 7 Bytes Revision Date 
It is intended for dynamic bad block 
handling. The revision date is the date on which the file 
was last deaccessed after being accessed for 
SC.MDL Set if the file is marked for delete. write. It is stored in ASCII in the form 
If this bit is set, further accesses to "DDMMMYY", where DD is two digits representing the 
the file are denied, and the file will day of the month, MMM is three characters 
be physically deleted when no uSers are representing the month, and YY is the last two 


accessing it. digits of the year. 
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344.2.56 I.RVTI & Bytes Revision Time sequential extension header for this file. If 
there is no extension header, or if the extension 
The revision time is the time of day on which the header is located on the same unit as this header, 
file was last deaccessed after being accessed for this byte contains Af. 
write. It is stored in ASCII in the’ format 
“HHMMSS", where HH is the hour, MM is the minute, 3.4.3.3 M.EFNU 2 Bytes Extension File Number 


and SS is the second. 
This word contains the file number of the next 


3.4.2.7 I.CRDT 7 Bytes Creation Date sequential extension header for this file. If 
there is no extension header, this word contains 
These seven bytes contain the date on which’ the A. 
file was created. The format is the same as that 
of the revision date above. 3.4.3.4 M.EFSQ 2 Bytes Extension File Sequence Number 
3.4.2.8 TaCRT I 6 Bytes Creation Time This word contains the file sequence number of the 
next sequential extension header for this file. 
These six bytes contain the time of day at which If there is no extension header, this word 
the file was created. The format is the same as contains f#. 
that of the revision time above. 
3.4.3.5 M.CTSZ 1 Byte Block Count Field Size 
eae BaD T.EXDT 7 Bytes Expiration Pate 
| This byte contains a count of the number of bytes 
These seven bytes contain the date on which the used to represent the count field in the retrieval 
file becomes eligible to be deleted. The format pointers in the map area. The retrieval pointer 
is the same as that of the revision and creation format is described in section 3.4.3.9 below. 
dates above. 
3245 366 M.LBSZ 1 Byte LBN Field Size 
3.4.2.18 7 1 Byte (unused) 
This byte contains a count of the number of bytes 
This unused byte is present te round up the _ size used to represent the logical block number field 
if the ident area to a word boundary. in the retrieval pointers in the map area. The 
contents of M.CTSZ and M.LBSZ must add up to an 
344.2% 11 8s LDHD 46 Bytes Size of Ident Area even number. 
This symbol represents the size of the ident area a4 3e7 M.USE 1 Byte Map Words In Use 


containing all of the above entries. 
This byte contains a count of the number of words 
in the map area that are presently occupied by 


! 
t 
| 
| Resta ds Map Area Description retrieval pointers. 
| 
| 


The map area of the file header starts at the word 4.4. 38 M.MAX 1 Byte Map Words Available 
indicated by H.MPOF. It contains the information necessary 
to map the virtual blocks of the file to the logical blocks This byte contains the total number of words 
of the volume. available for retrieval pointers in the map area. 
fog 
3.4.3.1  M.ESON 1 Byte Rxtension Segment Number 3.4.3.9 M.RTRV variable Retrieval Pointers 
This byte contains the value n, where this header This area contains the retrieval pointers that. 
is the n+ith header of the file; i.e., headers of actually map the virtual blocks of the file to the 
a file are numbered sequentially starting with @. logical blocks of the volume. Bach retrieval 
pointer describes a consecutively numbered group 
Da Bre te M.ERVN 1 Byte Extension Relative Volume No. of logical blocks which is part of the file. The 
count field contains the binary value nto 
This byte contains the relative volume number of represent a group of n+l logical blocks. The 
the unit in the volume set that contains the next logical block number’ field contains the logical 
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block number of the first logical block in_ the 
group. Thus each retrieval pointer maps virtual 
blocks } through j+n into logical blocks k through 
k+n, cespectively, where j is the total number 
plus one of virtual blocks represented by all 
preceding retrieval pointers in this and all 
preceding headers of the file, n is the value 
contained in the count field, and k is the value 
contained in the logical block number field. 


Although the data in the map area provides for 
arbitrarily extensible retrieval pointer formats, 
Files-11 has defined only three. Of these, only 
the first is currently implemented; the other two 
are presented out of historical interest; they 
will never be supported. 


Format 1: M.CTSZ 
M.LBSZ 


il 
3 


i 


The total retrieval pointer length is 
four bytes. Byte 1 contains the high 
order bits of the 24 bit  LBN. Byte 2 
contains the count field, and bytes 3 
and 4 contain the low 16 bits of the 
LBN. 


Format 2: M.CTSZ 
M. LBSZ 


i 
nN 


2 


The total retrieval pointer length is 
four bytes. The first word contains a 
16 bit count field and the second word 
contains a 16 bit LBN field. 


| Count ] 

 nheteeahanetenabaiatenehanetenananannta 

LBN | 

 oleieiehatetaienehenehehenenenanenananane | 
Format 3: M.CTSZ = 2 

M.LBSZ = 4 


The total retrieval pointer length is 
six bytes. The first word contains a 16 
bit count field and the second and third 
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3.4.3.1f 


3.4.4 


words contain a 3? bit LBN field. 


| Count | 

| --------------------- | 

| High | 

|-- LBN -~| 

| Low | 

| ----- aa nnannnnnnn---- | 
S.MPHD 1® Bytes Size of Map Area 


This symbol represents the size of the map area, 
not including the space used for the retrieval 
pointers. 


End Checksum Description 


The header check sum occupies the last two bytes of the 
file header. It is verified every time a header is read, 
and is recomputed every time a header is written. 


3.4.4.1 


H.CKSM 2 Bytes Block Checksum 


This word is a simple additive checksum of all 
other words in the block. It is computed by the 
following PDP-11 routine or its equivalent: 


MOV Header-~address,Rg@ 
CLR Rl 
MOV #255.,R2 
19S: ADD (R@)+,R1 
SOB R2,190$ 
MOV Rl, (R@) 
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3.4.A File Header Layout 


Header Area 


H.MPOF | Map Area Offset | Ident Area Offset | 


 octatatatotatekekelahetatatababeatatatel tatekataketatahabatahabatababababatetell| 


| File Number | 


| wae nn nn nnn | 


| File Sequence Number 


| pane nnn nnn nnn nnn nnn | 


| File Structure Level | 


| a------ raha acl laa Sie A a ern ro asa | 
H. PROT | File Owner UIC | 
 oohahetatetenbates eae Sa RRhanahatntnnahahanenananananenanananenatmnanal 
| File Protection | 
ee Os 
H.SCHA System Char. | User Char. 


User Attribute Area 


Ident Area 


| wenn nn nnn nn nnn nen | 


a2 ae 


File Name | 


_—— 


enn nn nn nn nn ne nnn | 


File Type 


ke en | 


Version Number | 


a nn nn nn nnn nee | 


Revision Number | 


| a ee ee rte ee le eit A wl ee cette en lle ee ete wie we alls ae we a wie en ey ie ee ee ee te i te | 


a fated She Seca Sete et eee al Sales Sulsereede doe’ 


—— --| 
Revision Date | 

~- --| 
| 

Aan nam enn nnn nn | -~| 


I. RVTI | | 


 echeahehatadateetatentntatetatetetatates 


-- Revision Time ~~ | 
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H. IDOF 


H. ENUM 


H.FSEQ 


H.FLEV 


H. FOWN 
H. PROG 


H.F PRO 


H.FCHA 
H.UCHA 


H.UFAT 


S. HDHD 


I. FNAM 


I.FTYP 


I. FVER 


I.RVNO 


I.RVDT 
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I.CRDT 


Map Area 


M.ERVN 


M.LBSZ 


M.MAX 


| am 
as | ~+---- 4 ee ee 
an ~- 


Creation Date 


[eeees ~~ | 
| Hite een ene Ree eee eRe ees 
|~- --| 
|-~ ~-| 
| MA Ko on eet nee eee een ee ee eee eee wen | 
oars ~= | 
‘ : 
a 

| Expiration Date | 
| sarcee | 

sed 
| (not use 
| - ann nen nnn nnn nnn nn | en enn nese | 
[ ~-----++-+ 4444-2 es | 72+ enn | 

: 

| Extension RVN | Ext. Seg. Num. | 


| Extension File Number | 


| maw nnn nen nn nn ne en en + | 


Extension File Seq. Num. | 


| wane nn nen nn | --- ie ee ee te oe ae 
| LBN Field Size | Count Field Size | 
| Map Words Avail. | Map Words in Use | 


| 
| 
| 
Retrieval Pointers | 
| 
| 
| 


ee Pe ite a ae ee ee i ly in a nO we ee ae a tome eS ete ie well we wl I ete wen tte wt | 


File Header Checksum | 


ee al ee ee et om | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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I.CRTI 


I. EXDT 


S.IDHD 


M.ESON 
M.EFNU 
M.EFSO 
M.CTSZ 
M.USE 


S.MPHD 
M.RTRV 


H.CKSM 
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Files-11 provides directories to allow the organization directory entry. 
of files in a meaningful way. While the File ID is 
sufficient to locate a file uniquely on a volume set, it ‘is Name The name of the file may be up to 9. characters. 
hardly mnemonic. Directories are files whose sole function It is stored as three words, each containing three 
is to associate file name strings with File ID's. Radix-5@ packed characters. 
Type The type of the file (also historically referred 
4.1 Directory Heirarchies to as the extension) may be up to. three 
characters. It is stored as one word of Radix-56@ 
Since directories are files with no special attributes, packed characters. 
directories may list files that are in turn directories. 
Thus the user may construct directory heirarchies of Version The verSion number of the file is stored in binary 
2 arbitrary depth and complexity to structure his files as he in one word. 
pleases, 
 onahenetetahabanenahehatatarmtatatanananall 
4.1.1 User File Directories | . 
| oo noms _e 
Current implementations of Files-11 all support a two j File ID { 
level directory heirarchy which is tied in with the user |-- —— | 
identification mechanism of the operating system. Each UIC | | 
is associated with a user file directory (UFD). References  otetetetetatetetetetetetetetatetetetateted| 
to files that do not specify a directory are generally | | 
defaulted to the UFD associated with the user's UIC. All — --| 
UFD's are listed in the volume's MFD under ae file name | Name | 
constructed from the UIC. A UIC of [n,m] associates with a j-~ --| 
directory name of "nnnmmm.DIR;1", where nnn and mmm are ~n | | 
and m padded out to three digits each with leading zeroes. | ann nnn nnn nnn | 
Note that all number conversions are done in octal. | Type 
panei cece e anes eeees oa 
Two points should be noted here. The UFD structure I Version | 
described here is not intrinsically part of the Files-ll  Rotahanatahatatahatananenaateneanatananedl 
on-disk structure; rather, it is a convenient cataloging 
System applied by various operating systems. Also, there is 
no hard and fast relationship between the owner UIC of a 4.3 Directory Protection 
File and the UFD in which it is listed. Generally, they 
will correspond, but not necessarily. Since directories are files with no special 
characteristics, they may be accessed like all other files, 
and are subject to the same protection mechanism. However, 
4.2 Directory Structure implementations of Files~+1l support three special functions 
for the management of directories, namely FIND, REMOVE, and 
A directory is a file consisting of 16 byte records. ENTER. A user performing such a directory operation must 
It is structured as an FCS fixed length record file, with no have the following privileges to be allowed the various 
carriage control attributes (see section 6 for a description functions: 
of FCS files). Each record is a directory entry. The 
entries are not required to be ordered, or densely packed, Find: READ 
nor do they have any other’ relationship to each other, Remove: READ, WRITE 
except that no two entries in one directory may contain the Enter: READ, WRITE 
same name, type, and version. Each entry contains the 
following: i Note that the same privilege is required for both enter and 
remove. The recovery for an operation that involves a 
File In The three word binary File ID of the file that remove at the beginning of the sequence is an enter. 
this directory entry represents. If the file 
number portion of the File ID field is zero, then 
this record is empty and may be used for a new * 
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5.4 Known Files 
Clearly any file system must maintain some data 


Structure on the medium which is used to control the file 
organization. In Files-11 this data is kept in five files. 
These files are created when a new volume is initialized. 
They are unique in that their File ID's are known constants. 
These five files have the following uses: 


File ID 1,1,@ is the index file. The index file is the 
root of the entire Files-11 structure. It contains the 
volume's bootstrap block and the home block, which is used 
to identify the volume and locate the rest of the file 
structure. The index file also contains all of the _ file 
headers for the volume, and a bitmap to control the 
allocation of file headers. 


File ID 2,2,@ is the storage bitmap file. I[t is used 
to control the allocation of logical blocks on the volume. 


File ID 3,3,@ is the bad block file. It is a file 
containing all of the known bad blocks on the volume. 


File ID 4,4,@ is the volume master file directory (or 
MFD) . It forms the root of the volume's. directory 
structure. The MFD lists the five known files, all first 
level user directories, and whatever other files the user 
chooses to enter. 


File ID .5,5,8 is the system core image file. Its use 
is operating system dependent; its hasic purpose is to 
provide a file of known File ID for the use of the operating 
system. 


2a | Index File 


The index file is File ID 1,1,@. It is listed in the 
MFD as INDEXF.SYS;1. The index file is the root of the 
Files-ll structure in that it provides the means for 
identification and initial access to a Files-11 volume, and 
contains the access data for all files on the volume 
(including itself). 


ak ed. Bootstrap Block 


Virtual block 1 of the index file is the volume's boot 
block. It is always mapped to logical block @ of the 
volume. If the volume is the system device of an operating 
system, the boot block contains an operating system 
dependent program which reads the operating system into 
memory when the boot hlock is  read_ and executed by a 
machine's hardware bootstrap. If the volume is not a system 
device, the boot block contains a small program that outputs 
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a message on the system console to inform the operator to 
that effect. 


Sie ae Home Block 


Virtual block 2 of the index file is the volume's home 
block. The logical block containing the home block is the 
first good block on the volume out of the sequence 1, 254, 
512, 768, 1924, 1280, .... 256n. The purpose of the home 
block is to identify the volume as Files-11, establish the 
specific identity of the volume, and serve as the ground 
zero entry point into the volume's file structure. The home 
block is recognized as a home block by the presence of 
checksums in known places and by the presence of predictable 
values in certain locations. 


Items contained in the home block are identified by 
symbolic offsets in the Same manner as items in the file 
header. The symbols may be defined in assembly language 
programs by calling and invoking the macro HMBOFS, which may 
be found in the macro library of any system that supports 
Files-1l1. Alternatively, one may find the macro in the file 
FIIMAC.MAC, which is available from the author. 


Sadie ves H. IBSZ 2 Bytes Index File Bitmap Size 


This 16 bit word contains tthe number of blocks 
that make up the index file bitmap. (The index 
file bitmap is discussed in section 5.1.3.) This 
value must be non-zero for a valid home block. 


Sie 2s2 H. IBLB 4 Bytes Index File Bitmap LBN 


This double word contains the starting logical 
block address of the index file bitmap. Once the 
home block of a volume has been found, it is this 
value that provides access to the rest of the 
index file and to the volume. The LBN is_ stored 
with the high order in the first 146 bits, followed 
by the low order’ portion. This value must be 
non-zero for a valid home block. 


Sele de S H. FMAX 2 Bytes Maximum Number of Files 


This word contains the maximum number of files 
that may be present on the volume at any time. 
This value must be non-zero for a valid home 
block. 


5.1.2.4 H.SBCL 2 Bytes Storage Bitmap Cluster Factor 
This word contains the cluster factor used in the 


Storage bitmap file. The cluster factor is the 
number of blocks represented by each bit in the 
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storage bitmap. Volume clustering can not 
implemented in ODS-1; the only legal value for 
this item is l. 
H.DVTY 2 Bytes Disk Device Type 

This word is an index identifying the type of disk 
that contains this volume. It is currently not 
used and always contains 4@. 

H.VLEV 2 Bytes Volume Structure Level 

This word identifies the volume's structure level. 
Like the file structure level, this word 
identifies the version of Files-11 which created 
this volume and permits upwards compatibility of 
media as Files-1l evolves. The volume = structure 
level is affected by all portions of the Files-11 
structure except the contents of the file header. 
This document describes Files~11 version 1; the 
only legal values for the structure level are 4@1 
and 42 octal. The former (40@1) is the standard 
value for most volumes. The latter (442) is an 
advisory that the volume contains a multiheader 
index file. (A multiheader index file is required 
to support more than about 26,4060 files. The 
index file may in fact be multiheader without the 
volume having a structure level of 482). 


H. VNAM 12 Bytes Volume Name 


This area contains the volume label as an ASCII 
String. It is padded out to 12 bytes with nulls. 
The volume label is used to identify individual 


Files-1l volumes. 


- 4 Bytes Not Used 


H. VOWN 2 Bytes Volume Owner UIC 

This word contains the binary UIC of the owner of 
the volume. The format is the same as that of the 
file owner UIC stored in the file header. 


H. VPRO 2 Bytes Volume Protection Code 

This word contains the protection code for the 
entire volume. Its contents are coded in the same 
manner as the file protection code stored in the 
file header, and it is interpreted in the same way 
in conjunction with the volume = owner UIC. All 
operations on all files on the volume must pass 
both the volume and the file protection check to 
be permitted. (Refer to the discussion on file 
protection in section Se ae ees ee 
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H.VCHA 2 Bytes Volume Characteristics 
This word contains bits which provide additional 
control over access to the volume. The following 


bits are defined: 


CH.NDC Obsolete, used by RSX=-11D/IAS. Set if 
device control functions are not 
permitted on this volume. Device 


control functions are those which can 
threaten the integrity of the volume, 
such as direct reading and writing of 
logical blocks, etc. 


Obsolete, used by RSX=-11D/IAS. Set if 
the volume may not he attached, i.e., 
reserved for the sole use by one task. 


CH.NAT 


CH.SDI Set if the volume contains only a single 
directory. If this bit is set, no 
directories should be created on the 
volume other than the MFD. The access 
methods should also be informed of this 
Situation, e.g. by setting the DV.SDI 
bit in the device characteristics word. 


H.DFPR 2 Bytes Default File Protection 
This word contains the file protection that will 
be assigned to all files created on this volume if 
no file protection is specified by the user. 


~ 6 Bytes Not Used 


H.WISZ ] Byte Default Window Size 

This byte contains the number of retrieval 
pointers that will be used for the "window" (in 
core file access data) when files are accessed on 
the volume, if not otherwise specified by the 
accessor. 

H.FIEX 1 Byte Default File Extend 

This byte contains the number of blocks that will 
be allocated to a file when a user extends the 
file and asks for the system default value for 
allocation. 

H. LRUC 1 Byte Directory Pre-access Limit 
This byte contains a count of the number of 
directories to be stored in the file system's 


directory access cache. More generally, it is an 
estimate of the number of concurrent users of the 


; 
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volume and its use may be generalized in the 
future. 


H.REVD 7 Bytes Date of Last Home Block 
Revision 


This field ill defined field is in the standard 
ASCII date format and reflects the date of the 
last modifications to fields in the home block. 


H.REVC 2 Bytes Count of Home Block Revisions 


This field reflects the number of above mentioned 
modifications. 


- 2 Bytes Not Used 
H.CHK1 2 Bytes First Checksum 


This word is an additive checksum of all entries 
preceding in the home block (i.e., all those 
listed above). It is computed by the same sort of 
algorithm as the file header checksum (see section 
324.421), 


H.VDAT 14 Bytes Volume Creation Date 


This area contains the date and time that the 
volume was initialized. It is in the format 
“DDMMMYYHHMMSS", followed followed by a _= single 
null. (The same format is used in the ident area 
of the file header, section 3.4.2). 


= 382 Bytes Not Used 


This area is reserved for the relative volume 
table for volume sets. This field will not be 
used, although some versions of MSC. referenced 
this area. 


5.1.2.21 H.PKSR 4 Bytes Pack Serial Number 


This area contains the manufacturer supplied 
serial number for the physical volume. For last 
track devices, the pack serial number is contained 
on the volume in the manufacturer data. For other 
devices the user must supply this’ information 
manually. The serial number is contained in the 
home block for convenience and consistency. 


Sade 2a22 - 12 Bytes Not Used 
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Seda2e23 


5.1.2.24 


521.2.25 


5.1.2.26 


5.1.2. 27 


H. INDN 12 Bytes Volume Name 


This area contains another copy of the ASCII 
volume label. It is padded out to 12 bytes with 
Spaces. It is placed here in accordance with’ the 
volume identification standard (STD 147). 


H. INDO 12 Bytes Volume Owner 


This area contains an ASCII expansion of the 
volume owner UIC in the form "[proj,prog]".- Both 
numbers are expressed in decimal and are padded to 
three digits with leading zeroes. MThe area is 
padded out to 12 bytes with trailing spaces. It 
is placed here in accordance with the volume 
identification standard (STD 147). 


H. INDF 12 Bytes Format Type 


This field contains the ASCII string "“"DECFILE11A" 
padded out to 12 bytes with spaces. It identifies 
the volume as being of Files-11 format. It is 
Placed here in accordance with the volume 
identification standard (STD 167). 


= 2 Bytes Not Used 
H.CHK2 2 Bytes Second Checksum 
This word is the last word of the home block. Et 
contains an additive checksum of the preceding 255 


words of the home block, computed according to the 
algorithm listed in section 3.4.4.1. 
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5.1.2.A Home Block Layout [| a, 
| 


| Se le Ae ee A ee we Ae ln we tts Se wa ee le ee ee ie le le wt Ve wl wl ity win ws win ls te whe 


| 

| 

| le te atten alin alin ole ee wn le ale ate ete ate ee Aan nn nn nn nnn nnn nnnne | | * 4 : | 
; a } Volume Modific 

| 

| 


; not used 
Soaks ~~ | | First Checksum H.CHK1 


H. VDAT 


| Bitmap LBN | 


Maximum Number of Files | H. FMAX [=~ aS 


~- (not used) -- 


| 
eer ere ucts ee een | : 
| Storage Bitmap Cluster Factor | H.SBCL ses | 
Sa haleheahatahanetanetatahananehahanahenahanaanaanenanensananal 
| Disk Device Type | H.DVTY fave ws 
eer i ee ae ee eee eee ey i Volume Creation Date | 
| Volume Structure Level | H. VLEV ele Soi 
| -----+---- ann nanan nnn nana nnn nana n-ne | 
| | H.VNAM oe 
es --| | 
| | oe ee 
[-— ~-| | 
| Volume Name | Atala then eee n enone ana nsaneceeun ce 
| ~~ om, | 
| | | 
[-- macs | 
| | | 
J~- at | (not used) | 
| | | 
| ---------+------ +--+ +--+ ----| } 
| | | 
| 
| | | 
| 


H.PKSR 
| Volume Owner UIC | H. VOWN 


| el ee i rl te ee ate ee ee Ot eh ee | 


I I le en rl i Ms ae ie el a Ae le ee et ee te ee | 


H 
| Volume Protection | H. VPRO 
| 
i 
i 
{ 


| te ate ate at wie te wile ile ae eile le ete ele ee oe nn nen | 
| Volume Characteristics | H.VCHA 
| ~--~ te lie ele ele ae ete oe nnn mn nn nn nen nnn nnn nnn | eue 
| Default File Protection | H.DFPR 
: | tee gle ele ele alte alin mein aly ete wile wit an em nnn nen nnn nnn nn nee | wiasedee ee 
i: : : (not used) 
t alas —. aati poet 
: | (not used) | 
| -- ~-| _ - 
| | 
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H.REVD | | Directory Limit | H. LRUC H. INDN 


| wan nn nnn nnn ne | 


' 
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} 
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i H.FIEX | Def. File Extend | Def. Window Size | H.WISZ 
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| Volume Modification Date | Volume Name 
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| The index file bitmap starts at virtual block 3 of the 
index file and continues through VBN 2+m, where m is the 
| number of blocks in the bitmap. It is located at the 
. . logical block indicated by offset H.IBLB in the home block. 
| 


| ee ee te ate we ee Pe ae oe A ee ee tained ee te ee em annnn-- | e 
5.1.4 File Headers 
H. INDO 


| | 

| The rest of the index file contains all the file 
: | headers for the volume. The first 16 file headers (for file 
We SOWREE | numbers 1 to 16) are logically contiguous with the index 
file bitmap to facilitate their location; the rest may be 
= is allocated wherever the file system sees fit. Thus the first 
| 16 file headers may be located from data in the home block 
| ! (H.IBSZ and H.IBLB) while the rest must be located through 
| the mapping data in the index file header. The file header 
| | for file number n is located at virtual block 2+m+tn (where m 
| is the number of blocks in the index file bitmap). 


H. INDF 
522 Storage Bitmap File 


| 

| 

| 

| Format Type : . The storage bitmap file is File ID 2,2,96. It is listed 

fae ent in the MFD as BITMAP.SYS;1. The storage bitmap is used to 

control the available space on a unit. It consists of a 
storage control block which contains summary information 

3 . about the unit, and the bitmap itself which lists the 

availablilty of individual blocks. 

| 


[See eeee rete aera | 5.2.1 Storage Control Block 

(not used) | 

eas eeu satan 5s eo ee ey ® | Virtual block 1 of the storage bitmap is the storage 
| sounds Sono , H.CHK2 control block. It contains summary information intended to 
| SSeS RRR ee ON optimize allocation of space on the unit. The storage 


control block has the following format for disks with less 
than 4896126, (516,896 blocks): 


7 5.1.3 Index File Bitmap 

P : ; 2 : (3 bytes) Not used (zero) 

| The index file bitmap 1S used to control the allocation (1 byte) Number of storage bitmap blocks (less than 127) 
of file numbers (and hence file headers) . It is simply a (2 bytes) Number of free blocks in 1st bitmap block 

bit string of length n, where n is the maximum number of (2 bytes) Free block pointer in ist bitmap block 

files permitted on the volume (contained in offset H.FMAX in ; 

the home block). The bitmap spans over aS many blocks as is on 

necessary to hold it, i.e., max number of files divided by ; 

4096 and rounded up. The number of blocks in the bitmap is (2 bytes) Number of free blocks in nth bitmap block 

i contained in offset H.~IBSZ of the home block. (2 bytes) Free block pointer in nth bitmap block 


. . ; 5 : oa g ‘ k 
The bits in the index file bitmap are numbered (4 bytes) Shzenok, (Che ane rk dog ical Dieate 


sequentially from @ to n-l in the obvious manner, i.e., from ; i 

oGe d: 

right to left in each byte, and in order of increasing byte Rot Serge arene ses Oe ero ee tes 

i address. Bit j is used to represent file number jtl: if 

; ; ‘ ar Magee : (3 bytes) Not used (zero) 

the bit is l, then that file number is in uss; if the bit (1 byte) Number of storage bitmap blocks (greater than 126) 
is @, then that file number 15s not in use and may be (4 bytes) Size of the unit in logical blocks 
assigned to a newly created file. Pome Boe ess Not used ieee) 
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Note: Current implementations of Files-11 do not correctly 
initialize the word pairs containing number of free blocks 
and free block pointer for each bitmap block, nor are these 
values maintained as space is allocated and freed on the 
unit. They are therefore best looked upon as 2n_ garbage 
words and should not be used by future implementations of 
Files-11 until the disk structure is formally updated. 


522 s2 Storage Bitmap 


Virtual blocks 2 through n+l are the storage bitmap 
itself. It is best viewed as a bit string of length nm, 
numbered from @ to m-1, where m is the total number of 
logical blocks on the unit rounded up to the next multiple 
of 4096. The bits are addressed in the usual manner (packed 
right to left in sequentially numbered bytes). Since each 
virtual block holds 4896 bits, n blocks, where n = m/4896, 
are used to hold the bitmap. Bit j of the bitmap represents 
logical block j of the volume; if the bit is set, the block 
is free; if clear, the block is allocated. Clearly the 
last k bits of the bitmap are always clear, where k is’ the 
difference between the true size of the volume and m, the 
length of the bitmap. 


The size of the bitmap is limited to 256 blocks. In 
fact, due to existing implementations on all RSX systems, 
the retrieval pointers must be in one of the’ following two 
forms: 


1. A Single retrieval pointer mapping the entire BITMAP.SYS 
file. 


2. Two retrieval pointers, the first mapping the storage 
control bhlock only, and the second mapping the entire 
bitmap proper. 

This restriction limits ODS-1 to a volume of 40896255 blocks 

(1,444,488 blocks or about 5@% megabytes). 

os, Bad Block File 

The bad block file is File ID 3,3,8. It is listed in 

the MFD as BADBLK.SYS;1. The bad block file is simply a 

file containing all of the known bad blocks on the volume. 


Se ee | Bad Block Descriptor 


Virtual block 1 of the bad block file is the bad block 


descriptor for the volume. It is always located on the last 


good block of the volume. This block may contain a_ listing 
of the bad blocks on the volume produced by a bad block scan 
program or diagnostic. The format of the bad block data is 


Beeeet S CONSSOCRIOSS acDecet CSE Ca iter St fel Cae 


Files-11 On-Disk Structure Page 38 


identical to the map area of a file header, except that the 
first four entries (M.ESON, M.ERVN, M.EFNU, and M.FFSO) = are 
not present. The last word of the block contains the usual 
additive checksum. (See section 3.4.3 for a description of 
the map area.) This block is included in the bad block file 
to save the data it contains for future re-initialization of 
the volume. 


Bad Block Descriptor Layout 


LBN Field Size ] Count Field Size | 


Map Words Avail. | Map Words in Use | 


| 
| 
Retrieval Pointers . 
| 
| 


| Block Checksum | 
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5.4 Master File Directory 


The master file directory is File ID 4,4, "@. It is 
listed in the MFD (itself) as @@90@.DIR;1. The MFD is the 
root of the volume's directory structure. It lists the five 
known files, plus whatever the user chooses to enter. In 
the two level UFD structure described in section 4.1.1, the 
MFD contains entries for all user file directories. 


5.5 Core Image File 


The core image file is File ID 5,5,@. It is listed in 
the MFD as CORIMG.SYS;1. Its use is operating system 
dependent. In general, it provides a file of known File ID 
for the use of the operating system, for use aS a Swap area, 
for example, or aS a monitor overlay area, etc. 


6.G FCS File Structure 


File Control Services (FCS) is a user level interface 
to Files-1l. Its principal feature is a record control 
facility that allows sequential processing of variable 
length records and sequential and random access to fixed 
length record files. FCS interfaces to the virtual block 
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facility provided by the basic Files-1] structure. 


6.1 FCS File Attributes 


FCS stores attribute information about the file in the 
file's user attribute area (H.UFAT ~ see section 3.4.1.9). 
It uses only the first 7 words; the rest are ignored by 
FCS, but are reserved by DEC. (RMS uses an additional 3 
words, 14 words in all, for relative and indexed file 
attributes.) The following items are contained in the 
attribute area; they are identified by the usual symbolic 
offsets (relative to the start of the attribute area). The 
offsets may be defined in assembly language programs by 
calling and invoking the macro FDOFFS DEFSL. Flag values 
and bits may be defined by calling and invoking the macro 
FCSBTS. These macros are in the system macro library of any 
operating system that supports Files-1l. Alternatively, all 
these values are defined in the system object library of any 
system that supports Files-11, and may be obtained at link 
time. 


Ae ded F.RTYP i Byte Record Type 
This byte identifies which type of records are 


contained in this file. The following three 
values are legal: 


R.FIX Fixed length records. 

R. VAR Variable length records. 

R.SEQO Sequenced Variable Length records 
Gelw 2 F,RATT 1 Byte Record Attributes 


This byte contains record attribute bits that 
control the handling of records under various 
contexts. The following flag bits are defined: 


FD.FTN Use Fortran carriage control if set. 
The first byte of each record is to be 
interpreted as a standard Fortran 
carriage control character when the 
record is copied to a carriage control 
device. 

FD.CR Use implied carriage control if set. 


When the file is copied to a carriage 
control device, each record is to. be 
preceded by a line feed and followed by 
a carriage return. Note that the FD.FTN 
and FD.CR bits are mutually exclusive. 


FD. PRN Used to indicate that the two byte 


sequence number field for R.SEQ record 
format is to be interpreted as print 
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control information (see Section 6.2.3.1 
for format of print information). 


FD.BLK Records do not cross block boundaries if 
set. Generally, there will be dead 
Space at the end of each _ hlock; how 


this is handled is explained in the 
description of record formats in section 
6.2. 


F.RSIZ 2 Bytes Record Size 


In a fixed length record file, this word contains 
the size of the records in bytes. In a variable 
or sequenced variable length record file, this 
word contains the size in bytes of the longest 
record in the file. 


F.HIBK 4 Bytes Highest VBN Allocated 


This 32 bit number is a count of the number of 
virtual blocks allocated to the file. Since this 
value is maintained by FCS, it is usually correct, 
but it is not guaranteed since FCS is a user level 
package. 


F.EFBK 4 Bytes End of File Block 


This 32 bit number is the VBN in which the end of 
file is located. Both F.HIBK and F.EFBK are 
Stored with the high order half in the first two 
bytes, followed by the low order half. 


F.FFBY 2 Bytes First Free Byte 


This word is a count of the number of bytes in use 
in the virtual block containing the end of file; 
i.e., it is the offset to the first byte of the 
file available for appending. Note that an end of 
file that falls on a block boundary may _ be 
represented in either of two ways. If the file 
contains precisely n blocks, F.EFBK may contain n 
and F.FFBY will contain 512, or F.EFBK may contain 
n+1 and F.FFBY will contain @. 


S.FATT 14 Bytes Size of Attribute Block 
This symbol represents the total number of bytes 


in the FCS file attribute block. 


FCS File Attributes Layout 
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F.RATT | Record Attr. Record Type F.RTYP 
LAA e rene See e te ea aca at baa eal Ra 
| Record Size (Bytes) | F.RSIZ 

a a aa ac ae ean | 
| Highest VBN F.,HIBK 
[= ee 
| Allocated | 
| ee ele ete te ee ty oe win te ate te te ee ie ee tn we ee ele ee ee ee ee et ee te te ee ~| 
| End of File | F.EFBK 
er --| 
| VBN | 
| aaa anna nn nnn nnn nn nnn nnn nee | 
First Free Byte | F,FFBY 
| wana nn nnn nn nn nn nnn nnn nnn nnn n ne | S.FATT 


A.? Record Structure 


This section describes how records are packed in the 
virtual blocks of a disk file. In general, FCS treats a 
disk file as a sequentially numbered array of bytes. 
Records are numbered consecutively starting with 1. 


6.2.1 Fixed Length Records 


In a file consisting of fixed length records, the 
records are simply packed end to end with no additional 
control information. If the record length is odd, each 
record is padded with a single byte. The content of the pad 
byte is undefined. For direct access, the address of a 
record is computed as follows: 


Let: n = record number 
k = record size (in bytes) 
m = byte address of record in file 
q = number of records per block 
3 = VBN containing the start of the record 
i = byte offset within VBN j 
then h ((k+1)/2)2 (rounded up record length) 
m (n-1)h 
} = m/512+1 (truncated) 
i = m mod 512 . 


The previous discussion assumes that records cross block 
boundaries (that is, FD.BLK is not set). If records do not 
cross block boundaries, they are limited to 512 bytes, and 
the following equations apply (the variables are defined as 
above): 


((k+1)/2)2 (rounded up record length) 
51?/k (truncated) 

(n-1)/qtl (truncated) 

((n-1) mod q)h 


we 
i 
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Gated Variable Length Records 


In a file consisting of variable length records, 
records may be up to 32767 bytes in length. Each record is 
preceded by a two byte binary count of the bytes in_ the 
record (the count does not include itself). For example, a 
null record is represented by a single zero word. The byte 
count is always word aligned; i.e., if a record ends on an 
odd byte boundary, it is padded with a single byte. The 
content of the pad byte is undefined. 


If records do not cross block boundaries (FD.BLK is set), 
they are limited to a size of 514 bytes. A byte count of -1 
is used as a flag to signal that there are no more records 
in a particular block. The remainder of that block is then 
dead space and the next record in the file starts at the 
beginning of the next block. 


6.2.3 Sequenced variable Length Records 


The format of a sequenced file is identical to a 
variable length record file except that a two byte sequence 
number field is located immediately after the byte count 
field of each record. This field contains a binary value 
which is usually interpreted as the line number of that 
record (see Section 6.1.2 FD.PRN and Section 4.2.3.1). The 
sequence number is not returned as part of the data when a 
record is read, but is available separately. Note that the 
record byte count field counts the sequence number field as 
well as the data of the record. 


6.2.3.1 Format of Two Byte Print Control Field in = R.SEO 
Records 


If the FD.PRN bit is set in the record attribute then 
the two byte "sequence number" field is used to contain 
carriage control data for the record. Byte @ is print 
control information to act upon before the record data is 
output to a unit record device; byte 1 is print control 
information to act upon after the record data has heen 
output to a unit record device. 


The format of each byte is as follows: 


Bit 7 Bits 6-4 Meaning 

4) A No carriage control 

A count(1-127) "count" new lines (CR/LF) 
Bit 7 Bit 6 Bit 5 Bits 4-9 Meaning 
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1 “A 4) ASCII C@ set 
1 4) 1 ASCII Cl set 
1 1 a CODE (#-63) 
i 1 l - 

NOTE 
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ASCII char to 

output (CR,FF etc.) 
ASCII char (8 bit code) 
to output 

Device specific code 
Reserved 


The print control field is not currently supported 


by FCS or RMS-ll1. 
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